This proposal replaces all integer encodings in frames with a unified
variable-length encoding format.  It simplifies the encoding considerably, most
noticeably in the ACK frame, which I have largely rewritten.

This change increases the number of streams to 2^62, but reduces the number of
packets and octets per stream to that same number.  Both are very large values
anyway.  I kept the 2^10 scaling on the connection-level flow control window,
so that goes to 2^72 now.

The cost for ACK is a negligible decrease in efficiency for larger gaps or
ACK blocks (mainly between 64 and 255 in length).  This is counteracted by an
increase in efficiency if there are occasional ranges or gaps larger than 255,
which were previously very difficult to encode correctly.

As previously discussed, the timestamp format is removed.  In its place, we use
the same integer encoding, but with a scaling value, or exponent, that is
signaled in transport parameters, that should allow common ACK delays to be
expressed in fewer octets (an exponent of 0 only allows for 16ms to be encoded
in two octets, but the default exponent is 8, allowing up to 128ms of ACK delay
to be encoded on two octets with an 8us resolution).

I haven't made any changes for HTTP yet, I plan to do that in a separate PR.

This didn't turn out to be that disruptive.  I'm somewhat worried that I missed
something actually.  Given that the changes are small, I think that I would
prefer this over #887 for #877.

The most interesting change here is that extension frame types that mention
Stream IDs will have to change.  I am not aware of any proposed thus far, so
maybe it's not too much of a cost to bear.  It further confirms my view that we
shouldn't be using Stream IDs at this layer anyway.

Based on this, I don't see any need for a middle-ground change.  The biggest
cost here is in taking the larger Stream ID space, not in taking the integer
encoding.

And a nit